REMARKS 

1. Summary of Office Action Mailed March 15, 2006 

In the office action mailed March 15, 2006, with claims 1, 5, 7-13, 15-17, and 21-24 
pending, the Examiner (i) rejected claims 1, 5, 7, 9-12, 17, and 21-24 under 35 U.S.C. § 102(e) 
as being anticipated by U.S. Patent 6,522,880 Bl (Verma); (ii) rejected claims 13 and 15-16 
under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 6,999,435 B2 (Perras); and 
(iii) rejected claim 8 under 35 U.S.C. § 103(a) as being unpatentable over the combination of 
Verma and Farinacci, "RFC 2784 - Generic Routing Encapsulation (GRE)" (RFC 2784). 

2. Status of the Claims 

Presently pending in this application are claims 1, 5, 7-13, 15-17, and 21-24, of which 
claims 1, 5, 9, 13, 17, and 21-24 are independent. Claims 2-4, 6, 14, and 18-20 have been 
canceled. No claims are amended herein. 

3. Summary of the Claims 

The claims are directed in various ways to methods and systems for establishing 
connections with mobile nodes. According to the claims, an entity (such as a packet data serving 
node (PDSN)) having Mobile-IP foreign-agent functionality (a foreign agent) receives a 
registration request from a mobile node that is seeking to communicate via that foreign agent. 
The foreign agent assigns a tunnel identifier for use in facilitating the Mobile-IP communication 
for that mobile node. This tunnel identifier may be just a simple integer value. 

Note that the foreign agent maintains two tables: a tunnel table and a connection table. 
The tunnel table is indexed by tunnel identifiers, and each entry in that table essentially contains 
a pointer or reference to an entry in the connection table. The entry in the connection table is 
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where the foreign agent stores connection information, such as point-to-point protocol (PPP) 
information, related to the mobile node. 

The foreign agent then tunnels this registration request to the mobile node's home agent. 
Before doing so, the foreign agent inserts the assigned tunnel identifier into a key field in a 
tunnel header that the foreign agent uses to tunnel the registration request to the home agent. 
When the foreign agent receives a registration reply tunneled from the home agent, the reply has 
that same tunnel identifier in a key field in the tunnel header. The home agent has also stored 
that same tunnel identifier for use in the ensuing packet-data communication in which the mobile 
node will engage. Similarly, when the foreign agent receives packets tunneled from the home 
agent for the mobile node, those packets will be encapsulated in a tunnel header having that same 
tunnel identifier in a key field. 

Both to send the registration reply and these ensuing packets to the mobile node, the 
foreign agent will use the tunnel identifier to identify the connection to the mobile node. In 
particular, the foreign agent uses the tunnel identifier to identify an entry in the tunnel table, 
which, as stated, is indexed by tunnel identifiers, so this step is more akin to a direct lookup into 
an array than it is to searching for an entry in a visitor table, list, or cache that has one or more 
values that match a value (or values) found in an inbound packet. The foreign agent then uses 
the identified entry in the tunnel table to identify an entry in the connection table. Again, this 
entry in the connection table has connection information related to the mobile node. The foreign 
agent then forwards the packet to the mobile node over this identified connection. 

As a result of the claimed systems and methods, registration replies and other inbound 
packets may arrive at the mobile node more quickly than they otherwise would, due to the fast 
lookup by the foreign agent. 

12 

MCDONNELL BOEHNEN 
HULBERT & BERGHOFF LLP 
300 SOUTH WACKER DRIVE 
CHICAGO, ILLINOIS 60606 
TELEPHONE (312) 913-0001 



4. The Prior Art 
a. Verma 

Verma is directed to a method and apparatus for handoff of a connection between 
network devices. The basic problem addressed by Verma is maintaining the state of a 
connection when a mobile node moves from (i) communicating with a tunnel endpoint (a.k.a. 
connection endpoint or home agent) via a first tunnel initiator (a.k.a. connection initiator or 
foreign agent) to (ii) communicating with the tunnel endpoint via a second tunnel initiator. This 
handoff may occur when the mobile node moves from a coverage area of the first tunnel initiator 
to the coverage area of the second tunnel initiator. 

According to Verma, the first tunnel initiator receives a registration request from the 
mobile node, and responsively identifies the tunnel endpoint associated with that mobile node, 
and then sets up a first connection between the first tunnel initiator and the tunnel endpoint. This 
connection may be a Layer Two Tunneling Protocol (L2TP) tunnel, as described in RFC 2661. 
According to that specification, each of the first tunnel initiator and the tunnel endpoint would 
maintain a tunnel ID, which would "have local significance only." That is, "the same tunnel will 
be given different Tunnel IDs by each end of the tunnel." And the same goes for session IDs 
maintained at each end of the L2TP tunnel. (See RFC 2661, section 3.1) 

When the first tunnel initiator detects that the mobile node has left its coverage area, it 
sends two messages. The first message is sent to the tunnel endpoint, which causes the tunnel 
endpoint to store data related to the first connection in a connection table 254. The second 
message is multicast to one or more other tunnel initiators. Upon receiving the second message, 
the second tunnel initiator stores data related to the first connection in a handoff table 244. Upon 
receiving a registration request from the mobile node, the second tunnel initiator retrieves the 
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connection data from the handoff table 244, and contacts the tunnel endpoint to establish a 
second connection using the stored connection data. The tunnel endpoint retrieves its stored 
connection data from the connection table 254, and a second connection is established between 
the second tunnel initiator and the tunnel endpoint, which allows the mobile node to continue 
engaging in packet data communication without disruption. (See Verma, 7:61 to 9:61) 
b. Perras 

Perras is directed to a method, system and node for providing enhanced mobility in 
Simple IP telecommunication networks when performing L2TP tunneling. Similar to Verma, 
Perras is focused on maintaining data connectivity for a mobile station when that mobile station 
moves from (i) communicating with a terminal node (analogous to a home agent in a Mobile-IP 
context) via a first service node (analogous to a foreign agent) to (ii) communicating with the 
terminal node via a second service node. 

According to Perras, a mobile station establishes a connection with a first service node, 
which then extends that connection to the terminating node. The mobile station and the 
terminating node are thus linked by a PPP connection, and the first service node and the terminal 
node are linked by an L2TP tunnel. The first service node thus functions as a transparent router. 
The terminal node assigns the mobile station an IP address, and stores an association between 
that IP address, an identifier (username) for the mobile station, and a tunnel identifier associated 
with the tunnel to between the terminal node and the first service node. 

When the mobile station moves from the coverage area of the first service node to the 
coverage area of a second service node, the mobile station establishes a connection with the 
second service node, which then similarly extends that connection to the terminal node. The 
terminal node then checks to see if it has previously assigned an IP address to that mobile station 
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via another service node, determines that it has, and then reassigns the same IP address to the 
mobile station. The terminal node then stores an association between the mobile station's 
username, that same IP address, and a tunnel ID associated with the tunnel between the terminal 
node and the second service node. The terminal node also uses the tunnel ID associated with the 
first tunnel (between the terminal node and the first service node) to identify that the terminal 
node should tear down that first tunnel. The mobile station can then continue communicating 
using the same IP address via the second service node. (See Perras, 10:51 to 13:3, Figs. 5-7) 

5. Response to Examiner's Rejections 

a. § 102(e) Rejections Based on Verma 

The Examiner rejected claims 1, 5, 7, 9-12, 17, and 21-24 under 35 U.S.C. § 102(e) as 
being anticipated by Verma. Of these claims, the independent claims are claims 1, 5, 9, 17, and 
21-24. Each of these independent claims basically involves a foreign agent carrying out the 
following steps: (i) receiving a registration request from a mobile node; (ii) determining or 
assigning a tunnel identifier; (iii) sending the registration request to a home agent, where that 
registration request includes that tunnel identifier in a key field of a tunnel header; (iv) receiving 
packets from the home agent that have that same tunnel identifier in a key field of a tunnel 
header; (v) using that tunnel identifier from the packets to identify a connection to the mobile 
node; and (vi) sending the packets to the mobile node over that identified connection. 

Furthermore, with respect to using the tunnel identifier from the packets to identify the 
connection to the mobile node, each of the independent claims involves using that tunnel 
identifier to identify an entry in a tunnel table that is indexed by tunnel identifiers, and then using 
that identified entry to identify an entry in a connection table, where the entry in the connection 
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table comprises connection information (such as a PPP or other data-link-layer connection 
information) between the foreign agent and the mobile node. 

Verma does not disclose this approach, nor is Verma even focused on the problem of a 
foreign agent (tunnel initiator) receiving data for a mobile node, quickly identifying the correct 
mobile node, and routing the data to that mobile node. Verma is focused instead on the problem 
of maintaining a data session between a mobile node and a home agent (tunnel endpoint) when 
the mobile node moves from a first foreign agent to a second foreign agent. Verma addresses 
this problem by having the first foreign agent send a message to the home agent, which causes 
the home agent to store connection data in a connection table. The first foreign agent also 
multicasts connection data to, among other network entities, the second foreign agent, which 
stores that connection data in a handoff table. Upon receiving a registration request from the 
mobile node, the second foreign agent and the home agent use their stored connection data to 
bring the connection out of what is essentially a suspended state, and allow the communication 
between the mobile node and the home agent to continue. 

Thus, Verma's two tables are maintained by two separate network entities - the home 
agent and the second foreign agent, and neither table is related to identifying the connection 
between the foreign agent and the mobile node. Rather, each entity uses its respective table to 
re-establish the tunnel between the home-agent and the foreign agent. And in the case of this 
tunnel being an L2TP tunnel, each end of the tunnel will use a different tunnel ID to identify the 
tunnel, as explained in RFC 2661. 

In contrast, the independent claims that stand rejected based on Verma involve a foreign 
agent assigning a tunnel ID that both the foreign agent and the home agent will include in a key 
field of a tunnel header for packets that are sent between these two entities. That is, both entities 
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will use the same tunnel identifier. Furthermore, these independent claims involve the foreign 
agent maintaining both (i) a tunnel table (indexed by tunnel IDs and containing entries that 
identify entries in a connection table) and (ii) the connection table (containing information 
specifying connections between the foreign agent and the mobile node). The foreign agent uses 
the tunnel ID from received packets to identify an entry in its tunnel table, which again is 
indexed by those tunnel IDs; the entry in the tunnel table then points to an entry in the foreign 
agent's connection table, and that connection-table entry contains the necessary connection data 
to route the packets to the correct mobile node. 

In the one instance where Verma actually addresses how a foreign agent directs inbound 
packets from a home agent to the correct mobile node, it is clear that Verma does not disclose the 
approach of the independent claims. At column 4, lines 27-31, Verma states that "[e]ach data 
and control packet will contain the tunnel ID and call session ID assigned by the tunnel initiator 
30 to differentiate these packets from those of other tunnels and calls that may exist between the 
tunnel initiator 30 and tunnel endpoint 50." As explained above, Verma contemplates having 
each end of the tunnel use different tunnel IDs, and thus Verma does not disclose the claimed 
approach of having the foreign and home agent both use the tunnel ID assigned by the foreign 
agent. And even if it did disclose that concept, nowhere does Verma disclose the foreign agent 
using that tunnel ID to directly access a tunnel table that is indexed by tunnel IDs, thereby 
identify an entry in a connection table, and forward the data over the connection identified by 
that connection-table entry. Simply using a term such as "differentiate" is not enough. 

Thus, none of independent claims 1, 5, 9, 17, or 21-24 are anticipated by Verma, and 
Applicant respectfully requests reconsideration by the Examiner on that point. The Examiner 
also rejected dependent claims 7 and 10-12 as being anticipated by Verma. Claim 7 depends 
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from claim 5, and claims 10-12 depend from claim 9. Thus, claims 7 and 10-12 are allowable 
for at least the reason that they depend from an allowable claim, 
b. § 102(e) Rejections Based on Perras 

The Examiner rejected independent claim 13 as being anticipated by Perras. Claim 13 is 
directed to a system that comprises a PDSN that essentially carries out the same tunnel ID, 
tunnel table, connection table functionality described above with respect to the other independent 
claims. Like Verma, Perras does not disclose this approach. And like Verma, Perras is focused 
on maintaining continuity of a data session when a mobile station moves from (i) communicating 
with a terminal node via a first service node to (ii) communicating with the terminal node via a 
second service node. This may occur when the mobile station moves from the coverage area of 
the first service node to the coverage area of the second service node. 

As explained above, Perras addresses this problem in a Simple-IP context by (i) re- 
assigning the same IP address to the mobile station following the mobile station's move to the 
second service node and (ii) promptly tearing down the tunnel to the first service node. Thus, 
Perras is another reference that is focused on handoffs, and not on how a foreign agent can 
quickly and efficiently route data inbound from a home agent to the correct mobile node. 

In the few instances where Perras actually addresses how a foreign agent directs inbound 
packets from a home agent to the correct mobile node, it is clear that Verma does not disclose the 
approach of the independent claims. At column 8, lines 59-62, Perras states that "[f]rom thereon, 
the service node 112a only acts as a transparent forwarding router between the mobile station 
102 and the LNS 116 and is referred to as a L2TP access concentrator (LAC)." At column 11, 
lines 59-64, Perras states that "[w]hen IP packets are tunneled between the LNS 116 and the 
service node 112b, a L2TP header is added to the packets by the L2TP stacks 612 and 606, the 
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latter removing said L2TP header from said packets once tunneling is completed and packets exit 
the tunnel." Neither of these cites comes close to disclosing the approach of claim 13. 

As explained, Perras does not disclose a foreign agent (PDSN) using a tunnel ID the way 
claim 13 does; rather, Perras discloses the terminal node (home agent) using the tunnel ID to 
identify which tunnel to tear down (i.e. the one between the terminal node and the first service 
node) upon the mobile station moving from the first to the second service node. (See Perras, 
11:15-19) 

Thus, Applicant respectfully submits that Perras does not anticipate independent claim 
13, and respectfully requests reconsideration from the Examiner on that point. The Examiner 
also rejected dependent claims 15 and 16 as anticipated by Perras. Claims 15 and 16 depend 
from claim 13. Thus, claims 15 and 16 are allowable for at least the reason that they depend 
from an allowable claim. 

c. § 103(a) Rejection Based on Verma and RFC 2784 

The Examiner rejected claim 8 under 35 U.S.C. § 103(a) as being unpatentable over the 
combination of Verma and RFC 2784. Claim 8 depends from claim 5. As explained above, at a 
minimum, Verma does not disclose a foreign agent receiving packets for a mobile node from a 
home agent, where those packets include a tunnel ID - that the foreign agent itself assigned - in 
a key field of a tunnel header, and then using that tunnel ID to identify an entry in a tunnel table 
that is indexed by tunnel IDs, and using the tunnel-table entry to identify an entry in a connection 
table, where that connection-table entry contains connection information that the foreign agent 
uses to route the packets to the correct mobile node. RFC 2784 describes Generic Routing 
Encapsulation as a general matter, and does not make up for the described deficiency of Verma. 
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Thus, Applicant respectfully submits that claim 8 is patentable over the combination of Verma 
and RFC 2784, and respectfully requests reconsideration from the Examiner on that point. 

6. Conclusion 

Applicant respectfully submits that all of the pending claims are now in condition for 
allowance. Applicant further submits that the remarks in this response fully address the 
Examiner's rejections - both under § 102 and § 103 - with respect to all of the currently-pending 
claims. Furthermore, Applicant affirmatively states that it does not concede the merits of any of 
the Examiner's rejections, whether specifically addressed herein or not. Therefore, Applicant 
respectfully requests favorable action. Should the Examiner have any questions, the Examiner is 
encouraged to contact the undersigned at 312-913-0001. 

Respectfully submitted, 

McDonnell boehnen 
hulbert & berghoff llp 

Date: July 25, 2006 By: 

Daniel P. Williams 
Reg. No. 58,704 
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